System simulation method

ABSTRACT

A system simulation method preventing the simulation speed from lowering. An initialization section allocates an area corresponding to a certain area on a memory model to be accessed by a user hardware model, as a user hardware memory, on a computer memory. Memory access from the user hardware model is always made to the user hardware memory. An access control section enables memory access from a processor core model to the user hardware memory and controls the memory access so that no conflict occurs with the access from the user hardware model.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on, and claims priority to, JapaneseApplication No. 2005-217114, filed Jul. 27, 2005, in Japan, and which isincorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to system simulation methods, andparticularly to a system simulation method for performing computerverification of a function of a logic circuit containing both aprocessor core and user hardware.

2. Description of the Related Art

A model simulator of a system-on-chip (SoC) model containing both acentral processing unit (CPU) core and user hardware should implementboth a function to simulate the operation of the CPU for verifyingsoftware and a simulation function to verify the user hardwaresimultaneously.

FIG. 14 shows the configuration of a conventional SoC model simulator.

The conventional SoC model simulator includes a processor core model 901which models the functions of the CPU running software to be verified, auser hardware model 902 which models the functions of the user hardwareto be verified, a memory model 903 which models a memory having acertain structure, and a memory access application program interface(API) function 904. The memory access API function 904 converts datainto a format suited to the structure of the memory model 903 andaccesses the memory model 903 when called with an address, size, or thelike used as an argument. The processor core model 901 and the userhardware model 902 read and write the memory model 903 through thememory access API function 904.

The processor core model 901, the user hardware model 902, the memorymodel 903, and the memory access API function 904 are implemented bysoftware, and loaded into and executed by a personal computer (PC) or aworkstation. The SoC model simulator is hereafter referred to as asystem simulator.

In the conventional system simulator, a single memory model 903 managesthe memory space to maintain consistency. While either the processorcore model 901 or the user hardware model 902 is accessing the memorymodel 903 through the memory access API function 904, the other cannotaccess it until the access ends.

One proposed system simulator has one memory model each for the userhardware model and the processor core model in order to reduce theverification time, and an interface model is included to connect the twomodels to maintain consistency in information exchange (for example,refer to Japanese Unexamined Patent Application Publication No.2000-35898, paragraphs [0022] to [0031] and FIG. 1).

In the conventional system simulation, the processor core model 901 andthe user hardware model 902 access the memory model 903 through thememory access API function 904 used in common. This structure causes thesimulator to become slow as the frequency of access (calling of thememory access API function 904) increases.

Especially, a system in which user hardware frequently reads or writesdata in memory, such as an image processing system, has such a generalconfiguration that the user hardware handles image data processing andthe processor controls data processing by the user hardware and runs theoperating system (OS). When the operation of that type of system isverified by the conventional system simulator, a great amount of accessfrom the user hardware model 902 keeps the processor core model 901waiting for memory access, degrading the performance of the SoC model,such as significantly decreasing the speed. This problem has a greateffect on the development of software such as firmware to be verified bythe processor core model 901, adversely affecting the entire process ofthe SoC design.

In some configurations of the simulation model having one memory modeleach for the user hardware model and the processor core model and aninterface model for synchronizing those models, synchronization may befrequently performed. The frequent synchronization will decrease thesimulation speed extremely.

SUMMARY OF THE INVENTION

In view of the foregoing, it is an object of the present invention toprovide a system simulation method which can prevent simulation speedfrom decreasing.

To accomplish the above object, according to the present invention,there is provided a system simulation method for verifying, on acomputer, a function of a target logic circuit containing both aprocessor core and user hardware. This system simulation method uses aprocessor core model which models the functions of the processor core, auser hardware model which models the functions of the user hardware, anda memory model which models the structure of the memory of the targetlogic circuit, all of which being built on the computer, and includesthe following steps: An initialization section allocates a user hardwarememory corresponding to the area of the memory model used by thehardware model to a memory area of the computer, and changes the accessdestination of the user hardware model to the user hardware memory; andan access control section controls the access destination of theprocessor core model in accordance with an access request.

The above and other objects, features and advantages of the presentinvention will become apparent from the following description when takenin conjunction with the accompanying drawings which illustrate preferredembodiments of the present invention by way of example.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a concept of the present invention applied to anembodiment.

FIG. 2 is a functional block diagram of a system simulator of theembodiment of the present invention.

FIG. 3 is a view showing an example of access to a memory model of thepresent embodiment.

FIG. 4 is a flow chart showing a first procedure for selecting thememory to be accessed according to the present embodiment.

FIG. 5 is a flow chart showing a second procedure for selecting thememory to be accessed according to the present embodiment.

FIG. 6 is a block diagram showing the hardware configuration of thesimulator of the present embodiment.

FIG. 7 is a view showing a procedure for loading an execution program,according to the simulation method of the present embodiment.

FIG. 8 is a view showing a procedure for starting the execution program,according to the simulation method of the present embodiment.

FIG. 9 is a view showing a procedure for accessing data (outside a UHWmemory area) by a core model, according to the simulation method of thepresent embodiment.

FIG. 10 is a view showing a procedure for accessing data (in the UHWmemory area without conflict) by the core model, according to thesimulation method of the present embodiment.

FIG. 11 is a view showing a procedure for accessing data (in the UHWmemory with a conflict) by the core model, according to the simulationmethod of the present embodiment.

FIG. 12 is a view showing a procedure for ending simulation, accordingto the simulation method of the present embodiment.

FIG. 13 is a view showing a flow of processing when the simulationmethod of the present embodiment is multi-threaded.

FIG. 14 shows the configuration of a conventional SoC model simulator.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

An embodiment of the present invention will be described below withreference to the drawings. An overview of the invention applied to theembodiment will be described, and then the embodiment will be describedin detail.

FIG. 1 shows a concept of the present invention applied to theembodiment.

A system simulator according to the present invention is applied to asystem simulation for verifying a target logic circuit by using modelsimplementing the functions of different blocks of the target logiccircuit by software on a computer. The system simulator includes aprocessor core model 1, a user hardware model 2, a memory model 3, amemory access processing block 4, a user hardware memory 5, and a memorymanagement block 6. The target logic circuit includes a memory which hasa certain structure, user hardware which frequently accesses the memoryalone and executes certain computation, and a CPU core whichoccasionally references the result of computation by the user hardwareand, when necessary, controls the user hardware to change the processingor for other purposes.

The processor core model 1 models the functions of the CPU core of thetarget logic circuit. The processor core model 1 is built on a computerwhen a program implementing the functions of the CPU core is executed onthe computer. The processor core model 1, built on the computer, readstarget programs successively, decodes read data, and executes decodedinstructions. Memory access in this processing is made through thememory access processing block 4.

The user hardware model 2 models the functions of the user hardware ofthe target logic circuit. The user hardware model 2 is built on thecomputer when a program implementing the functions of the user hardwareis executed on the computer. The user hardware model 2, built on thecomputer, processes certain input signals successively in accordancewith the logic of the user hardware and connection information ofcircuit elements, and generates output signals. When the processor coremodel 1 issues a processing start instruction or when a certaincondition is satisfied, the user hardware model 2 executes a series ofcomputation and generates a result of computation. Memory access in theprocessing is made to the user hardware memory 5.

The memory model 3 models the memory structure of the target logiccircuit. The memory model 3 is built on the computer when a programimplementing data read or data write suited to the memory structure isexecuted on the computer. The memory model 3 includes an area forstoring a target program executed by the processor core model 1, an areafor storing information temporarily when the processor core model 1executes a program, and an area for storing data for computation by theuser hardware model 2. When the memory model 3 receives an accessrequest of a certain format suited to the memory structure, from thememory access processing block 4 and the memory management block 6, thememory model 3 reads or writes data and responds in a certain format.

The memory access processing block 4 receives a memory access requestfrom the processor core model 1 and, if the requested access address isnot in the user hardware memory 5, converts the address to a formatsuited to the data structure of the memory model 3, and accesses thememory model 3 to read or write data, in cooperation with the memorymanagement block 6. If the requested access address is in the userhardware memory 5, the memory access processing block 4 passes theaccess request to the memory management block 6.

The user hardware memory 5 is allocated on the memory of the computer,in correspondence with a storage area for computation to be accessed bythe user hardware model 2, in the area of the memory model 3, by thememory management block 6. This memory is a normal memory area(allocated by the OS of the computer) without structure and can beaccessed directly from the user hardware model 2. With this memory, theaccess speed by the user hardware model 2 can be enhanced, in comparisonwith when data is converted in accordance with the memory structure.

The memory management block 6 includes an initialization section 6 a, anaccess control section 6 b, and a reflection section 6 c, and performsmanagement processing to maintain consistency between the memory model 3and the user hardware memory 5. Before system simulation starts or whenthe memory space for the active user hardware is specified, theinitialization section 6 a allocates the user hardware memory 5corresponding to the access area on the memory model 3 to be accessed bythe user hardware model 2, on the memory of the computer, in accordancewith the initialization information, and changes the access destinationof the user hardware model 2 to the user hardware memory 5. Theinitialization information including the information of access area(start address, size, etc.) of the user hardware model 2 is set up inadvance in the target program loaded through the processor core model 1,for instance. On some occasions such as when the target program isloaded, the initialization section 6 a obtains the initializationinformation and performs initialization accordingly. When necessary, theinitialization section 6 a copies data stored in an area of the memorymodel 3 corresponding to the user hardware memory 5 into the userhardware memory 5 so that the contents agree with each other. Readaccess is made in the data format suited to the structure of the memorymodel 3.

The access control section 6 b checks whether the requested destinationaddress of the memory access request from the processor core model 1,obtained by the memory access processing block 4, is in the userhardware memory 5. If not, the access control section 6 b reports thefact to the memory access processing block 4 and causes the memoryaccess processing block 4 to execute memory access processing to thememory model 3. If the requested destination address is in the userhardware memory 5, the access control section 6 b accesses thecorresponding address of the user hardware memory 5. If an accessrequest conflict occurs between the processor core model 1 and the userhardware model 2, an access sequence is determined in accordance withpredetermined priority levels. If the user hardware model 2 has a higherpriority level, the access request of the processor core model 1 ishandled after the memory access by the user hardware model 2 ends. Ifthe processor core model 1 has a higher priority level, the accessprocessing of the user hardware model 2 is queued while the accessrequest of the processor core model 1 is handled, and then the accessright is passed to the user hardware model 2.

The memory access processing block 4 may check whether the requesteddestination address of the access request from the processor core model1 is in the user hardware memory 5. In that case, the access controlsection 6 b is called only when the memory access processing block 4judges that the requested destination address is in the user hardwarememory 5.

When simulation stops at the end, or at a break in debugging of softwarethat allows read access to the memory model 3, the reflection section 6c writes the contents of the user hardware memory 5 into the memorymodel 3 so that the contents agree with each other. The data isconverted into the data structure of the memory model 3 before they arewritten.

A procedure of system simulation utilizing the system simulator asdescribed above will be described.

The processor core model 1, the user hardware model 2, the memory model3, and the memory access processing block 4 of the target logic circuitare built on a computer used for simulation. When a target program isread prior to the start of simulation, the initialization section 6 a ofthe memory management block 6 allocates the user hardware memory 5 on amemory of the computer, in accordance with the designation of an accessarea in the memory model 3 accessed by the user hardware model 2,included in the initialization information of the target program. Then,the access destination of the user hardware model 2 is changed to theuser hardware memory 5. After that, the user hardware model 2 accessesthe user hardware memory 5 instead of the memory model 3.

Simulation starts, and the computation of the user hardware model 2starts in accordance with, for instance, a start instruction from theprocessor core model 1. Memory access from the user hardware model 2 ismade to the user hardware memory 5. Memory access from the processorcore model 1 is received by the memory access processing block 4, andeither the memory access processing block 4 or the access controlsection 6 b of the memory management block 6 checks whether therequested address is in the user hardware memory 5. If the requestedaddress is not in the user hardware memory 5, the memory accessprocessing block 4 performs conversion into a format suited to the datastructure of the memory model 3, and then data is read or writtenaccordingly. If the requested address is in the user hardware memory 5,the access control section 6 b accesses the address of the user hardwarememory 5, and reads or writes data accordingly. If the user hardwaremodel 2 also attempts to access the user hardware memory 5, exclusiveprocessing is performed. Memory access given a higher priority level inadvance is handled earlier, and after the access processing ends, theother memory access is handled.

When simulation ends, the reflection section 6 c of the memorymanagement block 6 copies the contents of the user hardware memory 5into the corresponding area of the memory model 3, and the contentsagree with each other. The same processing is performed at a break insoftware debugging.

The memory area to be accessed by the user hardware model 2 is providedbesides the memory model 3, so that the frequency of access conflictbetween the processor core model 1 and the user hardware model 2 can bereduced greatly. Consequently, the processor core model 1 and the userhardware model 2 can be executed in parallel, and the system simulationspeed can be increased.

The user hardware memory 5 is a computer memory without a structure andcan be accessed directly from the user hardware model 2, so that fasteraccess is enabled.

An example of application of the present embodiment to simulation of atarget logic circuit having a CPU core and user hardware operating inparallel will be described in detail with reference to the drawings.

FIG. 2 is a functional block diagram of the system simulator of theembodiment of the present invention. Elements identical to those in FIG.1 are indicated by the same reference characters.

The system simulator according to the present invention includes aprocessor core model (hereafter referred to as a core model) 1, a userhardware model (hereafter referred to as a UHW model) 2, a memory model3, a memory access API function 41, a user hardware memory (hereafterreferred to as a UHW memory) 5 a, a user hardware register (hereafterreferred to as a UHW register) 5 b, and a memory link API function 61.

The memory access API function 41 serves as the memory access processingblock 4, and is a function called at memory access by the core model 1.

In the UHW register 5 b, a value indicating the memory area to beaccessed by the UHW model 2, that is, the area to be accessed in the UHWmemory 5 a, is specified.

The memory link API function 61 is a function implementing the functionsof the memory management block 6 and handles memory access incooperation with the memory access API function 41.

The memory access API function 41 and the memory link API function 61will be described in detail.

The memory access API function 41 is called at memory access by the coremodel 1 and has a function to convert data into a format suited to thestructure of the memory model 3 and a function to link the memory linkAPI function 61.

The data conversion function will be described first. FIG. 3 is a viewshowing an example of access to the memory model 3 of the presentembodiment.

As described earlier, the memory model 3 is structured and must beaccessed in a data format suited to the structure. The structure mayhave a memory attribute of the SoC model and may require an accessrequest including the memory attribute, or the structure may requireprocessing to save the memory. If the SoC model uses the big-endianformat and if the computer uses the little-endian format, an endianconversion is necessary.

The core model 1 calls the memory access API function 41, using anaddress and size as arguments in read access or using an address andsize, and further data to be written as arguments in write access. Thememory access API function 41 carries out conversion to a data formatsuited to the structure of the memory model 3 as described above andmakes an access request. Read data is subjected to reverse conversionand is returned to the core model 1. The format depends on the model.

When the core model 1 requests to access an address in the UHW memory 5a, the function to link the memory link API function 61 asks the memorylink API function 61 to access the UHW memory 5 a.

FIG. 4 is a flow chart showing a first procedure for selecting thememory to be accessed according to the present embodiment. When the coremodel 1 accesses memory, the memory access API function 41 is called andstarts the processing.

Step S01: The function reads the range of the UHW memory area. The rangeof the UHW memory area is obtained by reading the initializationinformation stored in the memory model 3 or by reading values of the UHWregister 5 b through the memory link API function 61.

Step S02: The function compares the requested memory access destinationof the core model 1 with the range of the UHW memory area read in stepS01, and checks whether the requested access destination is included inthe UHW memory area. If yes, the processing proceeds to step S05.

Step S03: If the requested access destination is not included in the UHWmemory area, memory model structure adaptation is performed to convertthe access request into a data format suited to the structure of thememory model 3.

Step S04: The function accesses the memory model 3 in accordance withthe access request in the data format suited to the structure of thememory model 3 obtained in step S03, and then ends the processing.

Step S05: If the requested access destination is included in the UHWmemory area, the function calls the memory link API function 61 toaccess the UHW memory 5 a, and then ends the processing.

The address check may be performed by the memory link API function 61instead of the memory access API function 41.

The memory link API function 61 is called by the memory access APIfunction 41, and is also called when a certain condition is satisfied,such as at the end of simulation or a break in debugging. The memorylink API function 61 links the UHW memory 5 a with the memory model 3.More specifically, the memory link API function 61 has a function tohandle access to the UHW register 5 b, a function to handle access fromthe core model 1 to the UHW memory 5 a, an exclusive processing functionto be executed at an access conflict between the core model 1 and theUHW model 2, and a data match function to match the memory model 3 andthe UHW memory 5 a.

The function to handle access to the UHW register 5 b specifies the UHWmemory 5 a on the computer memory in initialization. The area of the UHWmemory 5 a used by the UHW model 2 depends on the register address andsize specified by the core model 1. The memory is specified byallocating the computer memory to memory variables (pointers) of theregisters. The start address and end address of the area of the UHWmemory 5 a can be found by specifying the start address and size in theregisters.

For instance, when the address (Reg1Addr) is set to “0x01000000” and thesize (Reg1Size) is set to “0x100” in a pair of registers 1, the memoryarea indicated by the pair of registers 1 has

a start address of Reg1Addr, and

an end address of (Reg1Addr+Reg1Size)

The UHW register 5 b can have a plurality of these register pairs.

The function to handle access from the core model 1 to the UHW memory 5a is called by the memory access API function 41 and starts theprocessing.

FIG. 5 a flow chart showing a second procedure for selecting the memoryto be accessed according to the present embodiment. The figure shows theprocedures of both the memory access API function 41 and the memory linkAPI function 61.

The memory access API function 41 is called at memory access by the coremodel 1 and starts the following processing.

Step S11: When a memory access request is obtained from the core model1, the function calls the memory link API function 61, sends the memoryaccess request, and starts the processing.

Step S12: The function starts memory model structure adaptation toconvert the access request into a data format suited to the memory model3, without waiting for a response from the memory link API function 61,in order to reduce the processing time.

Step S13: The function accesses the memory model 3.

The requested access destination of the memory model 3 is accessed byfollowing the processing procedure described above while a response fromthe memory link API function 61 is being waited for.

The memory link API function 61 activated in step S11 performs thefollowing processing.

Step S21: The function reads the range of the UHW memory area. The rangeof the UHW memory area is obtained by reading the values of the UHWregister 5 b.

Step S22: The function specifies a response of invalid memory access asan initial value. The function compares the requested memory accessdestination of the core model 1 and the range of the UHW memory arearead in step S21 to check whether the requested access destination is inthe UHW memory area. If the requested access destination is not includedin the UHW memory 5 a, the function performs nothing and goes to stepS24.

Step S23: If the requested access destination is included in the UHWmemory area, the function accesses the requested access destination ofthe UHW memory 5 a. In read access, the function reads data from thecorresponding area of the UHW memory 5 a and specifies a response toreport the read data and the fact that the memory access has been madesuccessfully. In write access, the function obtains the data to bewritten by the core model 1 through the memory access API function 41and writes the data in the corresponding area of the UHW memory 5 a. Ifan access conflict with the UHW model 2 occurs, exclusive processing,which will be described later, is performed. At the end of writing, thefunction specifies a response to report that the memory access has beenmade successfully.

Step S24: The function returns the response to the memory access APIfunction 41 and ends the processing. If the access destination is in theUHW memory 5 a, the response reporting the successful memory access(with the read data, in read access) has been specified in step S23. Ifthe access destination is outside the UHW memory 5 a, a responsereporting that the memory access is invalid has been specified in stepS22.

The continued processing of the memory access API function 41 will bedescribed.

Step S14: The function obtains the response and checks based on theresponse whether access to the UHW memory area has been performed, thatis, whether the memory access has been made successfully. If not, thefunction ends the processing and returns the result of the memory accessin step S13 is returned to the core model 1.

Step S15: If the response tells that the UHW memory area has beenaccessed (successful memory access), the function updates data inaccordance with the information obtained as the response. In readaccess, the function returns the data read from the UHW memory 5 a bythe memory link API function 61 to the core model 1. In write access,the function returns the result of successful writing in the UHW memory5 a by the memory link API function 61 to the core model 1.

In the description given above, in order to increase the processingspeed, steps S12 and S13 of the memory access API function 41 areperformed before a response is obtained from the memory link APIfunction 61. These steps may also be carried out after the response isobtained if the access destination is determined to be outside the UHWmemory area. Because data structure conversion by the memory access APIfunction 41 is generally time-consuming, steps S12 and S13 should beperformed before the determination, or, in access to the UHW memory 5 a,step 13 should be interrupted, to enable faster access.

The exclusive access processing function performs exclusive processingif a conflict occurs between access from the core model 1 to the UHWmemory 5 a and access from the UHW model 2 to the UHW memory 5 a. Accesshaving a higher priority level is handled earlier, in accordance withthe priority levels determined by the design specifications related tothe access right of the core model 1 and the UHW model 2. When firstaccess ends, the other access is performed. The major function of thecore model 1 is generally designed to perform general control and not tooverlap the processing by the UHW model 2. It is therefore assumed thatthe core model 1 and the UHW model 2 do not often share a memory area.The core model 1 and the UHW model 2 access different memory areasmostly.

The data match function between the memory model 3 and the UHW memory 5a matches the contents of the memory model 3 to the contents of the UHWmemory 5 a at a break in debugging software or firmware or at the end ofsimulation. The memory link API function 61 converts the data of the UHWmemory 5 a into a data format suited to the structure of the memorymodel 3 and transfers the data to the memory model 3.

The hardware configuration of the simulator implementing the simulationmethod of the present embodiment will be described. FIG. 6 is a blockdiagram showing the hardware configuration of a simulator 100 of thepresent embodiment.

The whole of the simulator 100 is controlled by a CPU 101. The CPU 101is connected through a bus 107 to a random access memory (RAM) 102, ahard disk drive (HDD) 103, a graphic processing unit 104, an inputinterface 105, and a communication interface 106.

The RAM 102 temporarily stores at least a part of an operating system(OS) and an application program to be executed by the CPU 101. The RAM102 also stores a variety of data necessary for processing executed bythe CPU 101. The HDD 103 stores the OS and the application program. Thegraphic processing unit 104 is connected to a monitor 108 and displaysan image on the screen of the monitor 108 as instructed by the CPU 101.The input interface 105 is connected to a keyboard 109 a and a mouse 109b, and sends a signal sent from the keyboard 109 a or the mouse 109 bthrough the bus 107 to the CPU 101. The communication interface 106 isconnected to a network and exchanges data through the network withanother apparatus.

A program implementing the above-described model of the target logiccircuit and an execution program are loaded into the simulator 100, andsimulation is performed.

The simulation method of the present embodiment will be described below.

FIG. 7 is a view showing a procedure for loading the execution program,according to the simulation method of the present embodiment.

An execution program (load module) 10 such as firmware is loaded beforean SoC model formed of the core model 1, the UHW model 2, the memorymodel 3, and the memory access API function 41 is started to beginsimulation.

The core model 1 writes the execution program 10 through the memoryaccess API function 41 into a certain area of the memory model 3. In theshown example, the execution program 10 is written in a memory area 31 aand a memory area 31 b. The execution program 10 includes instructioncodes, and initial values of data space setting, peripheral circuitsetting, register setting, and the like, or initialization instructionstherefor. The data space, peripheral circuit, and registers are set upby the execution program 10 or in accordance with the initializationinformation. The memory area of the user hardware model 2 is specifiedby a register. In the shown example, the register has not yet been set,and the UHW memory 5 a is not specified on the computer memory. When theregister of the UHW model 2 is specified at initialization, the UHWmemory 5 a is allocated simultaneously.

The operation to start the execution program 10 by the core model 1 willdescribed below.

FIG. 8 is a view showing a procedure for starting the execution program10, according to the simulation method of the present embodiment.

The execution program 10 may include a register write instruction whichspecifies the memory space to be used by the UHW model 2. If that typeof instruction is found, the core model 1 specifies an UHW area 32 inthe memory model 3 through the memory access API function 41 inaccordance with the instruction. At the same time, the core model 1writes the area setting of the UHW memory 5 a in the UHW register 5 bthrough the memory link API function 61 and allocates the UHW memory 5 aon the computer memory. Both the area 32 on the memory model 3 and theUHW memory 5 a are allocated as memory areas of the UHW model 2.

The operation performed when the core model 1 attempts to access the UHWmemory 5 a will be described.

When the core model 1 attempts to access memory, the memory access APIfunction 41 or the memory link API function 61 checks whether the memoryaccess destination is in the UHW memory 5 a. If not, the memory model 3is accessed through the memory access API function 41. If the UHW memory5 a includes the access destination, the UHW memory 5 a is accessedthrough the memory link API function 61.

The two cases will be described with reference to the drawings. In thedescription below, it is supposed that the memory access API function 41checks the range of the UHW memory area and that the memory access APIfunction 41 can read the contents of the UHW register 5 b directly. Thesame data as in the UHW register 5 b may be stored in an area that canbe read directly by the memory access API function 41, and referencedinstead of the data of the UHW register 5 b.

FIG. 9 is a view showing a procedure for accessing data (outside the UHWmemory area) by the core model 1, according to the simulation method ofthe present embodiment.

When the core model 1 attempts to access an area outside the UHW memory5 a, the memory access API function 41 is called. The memory access APIfunction 41 checks whether the requested access destination is in theUHW memory 5 a and finds that the access destination is not included.The memory access API function 41 accesses the corresponding area of thememory model 3. The memory link API function 61 is not started, as shownin the figure. The UHW model 2 can access the UHW memory 5 a asrequired, regardless of the access status of the core model 1. If theaccess destinations of the core model 1 and the UHW model 2 are indifferent address spaces (no access conflict), the core model 1 and theUHW model 2 can access the memory model 3 and the UHW memory 5 a,respectively, as required in parallel. Accordingly, a multi-threaded SoCmodel enables fast simulation.

An operation performed when the core model 1 attempts to access the UHWmemory 5 a and no conflict occurs with the UHW model 2 will bedescribed.

FIG. 10 is a view showing a procedure for accessing data (in the UHWmemory area without conflict) by the core model 1, according to thesimulation method of the present embodiment.

When the core model 1 attempts to access a memory area in the UHW memory5 a, the memory access API function 41 is called. The memory access APIfunction 41 checks whether the requested access destination is in theUHW memory 5 a, finds that the access destination is included, andpasses the memory access request to the memory link API function 61. Thememory link API function 61 checks the access status of the UHW model 2,and, if no conflict is found, accesses the UHW memory 5 a in accordancewith the access request of the core model 1 obtained through the memoryaccess API function 41. In read access, read results are returned to thecore model 1 through the memory access API function 41.

Because the core model 1 and the UHW model 2 do not conflict, the memoryareas can be accessed in parallel. Accordingly, a multi-threaded SoCmodel enables fast simulation.

An operation performed when the core model 1 attempts to access the UHWmemory 5 a and a conflict with the UHW model 2 occurs will be described.

FIG. 11 is a view showing a procedure for accessing data (in the UHWmemory with a conflict) by the core model 1, according to the simulationmethod of the present embodiment.

When the core model 1 attempts to access a memory area in the UHW memory5 a, the memory access API function 41 is called. The memory access APIfunction 41 checks whether the requested access destination is in theUHW memory 5 a, and because the destination is included, passes theaccess request to the memory link API function 61. The memory link APIfunction 61 checks the access status of the UHW model 2 and finds thatthere is a request to access the same space (conflict). If there aremultiple requests to access the same memory area, a request having ahigher priority level is executed by exclusive control. If the UHW model2 has a higher priority level, read or write access by the UHW model 2is performed first, then the UHW memory 5 a is accessed in accordancewith the access request of the core model 1 obtained through the memoryaccess API function 41. If the core model 1 has a higher priority level,the access request by the UHW model 2 is queued, the access request bythe core model 1 is handled, and then the access request by the UHWmodel 2 is dequeued. The priority levels depend on the specifications ofthe SoC model. The priority levels of write access may differ from thepriority levels of read access.

When a conflict occurs between access requests, the processing isperformed as described above. If an access request is made while accessis in progress, the ongoing access processing has precedence over theaccess request.

The operation to reflect the contents of the UHW memory 5 a into thememory model 3 after simulation or the like will be described.

FIG. 12 is a view showing a procedure for ending simulation, accordingto the simulation method of the present embodiment. The same processingis performed also at a break of debugging or in a pause of simulation.

When simulation stops, the memory link API function 61 is called. Thememory link API function 61 writes the contents of the UHW memory 5 ainto the corresponding UHW area 32 of the memory model 3 so that the UHWmemory 5 a and the memory model 3 have the same data. Before writingdata, the memory link API function 61 converts the data of the UHWmemory 5 a without structure into a format suited to the structure ofthe memory model 3.

Because the memory area for the UHW model 2 is allocated on the computermemory without structure, the core model 1 and the UHW model 2 canaccess respective memory areas in parallel without causing a conflict.Because the UHW memory 5 a for the UHW model 2 is allocated on thecomputer, the access speed by the UHW model 2 can be enhanced.Consequently, a multi-threaded SoC model enables fast simulation.

FIG. 13 is a view showing the flow of processing when the simulationmethod of the present embodiment is multi-threaded.

A thread to execute the core model 1 and a thread to execute the UHWmodel 2 proceed in parallel in a multi-thread configuration. The coremodel 1 executes processing in accordance with an execution programstored in the memory model 3 and specifies a UHW area of the memorymodel 3 as instructed. The UHW memory 5 a used by the UHW model 2 isallocated on the computer, and the UHW model 2 is specified to accessthe UHW memory 5 a.

The core model 1 activates the UHW model 2 when needed, in accordancewith the execution program. After activating the UHW model 2, the coremodel 1 continues the processing in parallel with the UHW model 2. TheUHW model 2 performs certain computation, accessing the UHW memory 5 a.The two threads proceed in parallel.

If an access request from the core model 1 to the UHW memory 5 a and anaccess request of the UHW model 2 conflicts with each other in thatstate, processing is performed in descending order of priority. In theshown example, data writing by the core model 1 is performed afteraccess by the UHW model 2, and data reading by the processor core model1 is performed before access by the UHW model 2.

The core model 1 and the UHW model 2 can access separate memory areas inparallel, enabling faster simulation.

In a system simulation method of the present invention, the processorcore, user hardware, and memory of the target logic circuit are modeledon a computer. A user hardware memory is provided besides the memorymodel, and the user hardware model accesses the user hardware memory.Because the processor core model accesses the memory model mostly, evenif a large amount of access is generated from the user hardware model tothe user hardware memory, a suppressed effect is imposed on the accessof the processor core model. Therefore, fast simulation is enabled.

The foregoing is considered as illustrative only of the principles ofthe present invention. Further, since numerous modifications and changeswill readily occur to those skilled in the art, it is not desired tolimit the invention to the exact construction and applications shown anddescribed, and accordingly, all suitable modifications and equivalentsmay be regarded as falling within the scope of the invention in theappended claims and their equivalents.

1. A system simulation method for verifying, on a computer, a functionof a target logic circuit containing a processor core and user hardware,the system simulation method using a processor core model which modelsthe functions of the processor core, a user hardware model which modelsthe functions of the user hardware, and a memory model which models thestructure of the memory of the target logic circuit, all of which beingbuilt on the computer, and comprising the steps of: an initializationstep allocating a user hardware memory corresponding to the area of thememory model used by the user hardware model to a memory area of thecomputer, and changing the access destination of the user hardware modelto the user hardware memory; and an access control step controlling theaccess destination of the processor core model in accordance with anaccess request.
 2. The system simulation method according to claim 1,wherein the access control step checks a memory access request from theprocessor core model with regard to whether the requested accessdestination is included in the memory area provided as the user hardwarememory; and, if the destination is not included, the memory model isdesignated as the access destination, or, if the destination isincluded, the user hardware memory is designated as the accessdestination.
 3. The system simulation method according to claim 2,wherein the access control step handles an access request having ahigher priority level earlier in accordance with predetermined prioritylevels when the access destination of the processor core model is in theuser hardware memory and when the user hardware model makes an accessrequest to the same memory area.
 4. The system simulation methodaccording to claim 2, wherein the access control step does not executeprocessing for the memory access request from the processor core model,with regard to the user hardware memory or the memory model which is notselected as the access destination of the processor core model.
 5. Thesystem simulation method according to claim 1, wherein theinitialization step allocates the user hardware memory to the memoryarea of the computer in accordance with initialization informationspecified in a target program to be executed by the processor core modelwhen the target program is loaded into the memory model.
 6. The systemsimulation method according to claim 1, wherein a reflection stepreflects the contents of the user hardware memory into the memory model,at the end of the system simulation or in a pause of the systemsimulation.
 7. The system simulation method according to claim 6,wherein the contents of the user hardware memory are converted into aformat suited to the data structure of the memory model and then writteninto the memory model when the contents of the user hardware memory arereflected into the memory model.
 8. A system simulator for verifying afunction of a target logic circuit containing a processor core and userhardware, the system simulator comprising on a computer: a processorcore model block which models the functions of the processor core; auser hardware model block which models the functions of the userhardware; a memory model block which models the structure of a memory ofthe target logic circuit; a user hardware memory which is used by theuser hardware model block; an initialization means which allocates anarea corresponding to the area of the memory model block accessed by theuser hardware model block as the user hardware memory, in a memory areaof the computer; and a memory management block which, when an accessrequest is made from the user hardware model block to the memory modelblock, handles the access request to an area of the user hardware memorycorresponding to an area of the memory model block to be accessed.